Computer software programs often produce documents. Examples of such programs include word processors, spreadsheets, and graphic creators, among others. Documents normally contain data saved in a format that may or may not be specific to the piece of software used to create it. For example, a word processor may save a document in a format that only that word processor could read, or some word processors may have the ability to save a document in a format that other types of word processors or even other programs can read.
An e-commerce community comprises a number of entities, normally various businesses or applications within a single business, who exchange business documents with each other. Examples of documents typically exchanged in e-commerce communities include purchase orders, requests for quotes, and sales confirmations, among others. The entities exchanging the documents typically include trading partners, internal applications, and business services.
Exchange of these business documents normally is accomplished by defining a structure and representing the business logic in documents based on that structure. Often, a markup language, such as Extensible Markup Language (XML) is used. The documents may be wrapped in electronic messages and exchanged over an e-marketplace.
Each business document exchange may represent a named portion of a business transaction. However, the potential logic represented by the named business document may evolve over time. In the case of XML-based documents, a schema or DTD is updated and available data elements may be added, removed, or changed in new incarnations of the logic. This evolution of business document structure is called versioning.
Each new structure defines a new version of that business document. However, when dealing in an e-marketplace, it is quite common that one or more members of the trading community does not natively support all versions of all business documents traded in their community. This creates a situation where documents may be sent to entities that do not understand their structure.
Historically, formats used for the exchange of information such as Electronic Data Exchange (EDI) have solved this problem in one of two ways. The first solution is to define a community version and require that all participating entities (trading partners, internal applications, business services) comply with that community version. Two problems with this approach are potential data loss and synchronized migration.
A data loss example is two entities that natively support the same higher level document than the community version and translate to the community version before sending and back after receiving. If all the logic in the higher level document is not representable in the lower, this document exchange is not as rich as a pure native version exchange.
Another problem with this approach is that it requires potentially expensive coordination between entities to synchronize migration to a new document version.
The second solution is to force the receiver of the document to support all possible sender formats, perhaps by translating to a version he can understand. This solution also requires coordination migration of a community to a new version. If one member migrates to a new versions, all potential receivers from this member must be able to support this new version (perhaps via translation).
What is needed is a solution that allows for the exchange of documents with minimal data loss while still providing for independent migration by the participants.